\section{Lessons Learned}

\subsection*{Dennis}

One of the most painfully leaned lessons for me during this project
was the importance of a consistent and carefully thought about
contract between different modules. A strong enough architecture
model, and an eye towards dependencies means that each developer can
handle the internal implementation of different parts of the project
without having to constantly be aware of small changes in the details
of somebody else's work. We got worse at following this rule as the
project went along. Towards the end of the project, as the code
evolved more and more towards completion, a single change very early
on in the architecture model (say, a new keyword in the parser), had
to implemented all the way down the line to the compilation
stage. Particularly annoying was the fact that there were about six
different abstract stages at which an error could propagate. This made
last minute features (or, features we did not plan on when we created
the DiGr AST) slightly exasperating. In an ideal world, I think our
two ASTs and the backend would have been written first, and then the
modules worked on independently. In reality, development was
concurrent and intertwined.

\subsection*{Ari}

As the project neared its completion and we found ourselves testing out
the language, the thing that hit me the most was that its easier to
come up with a simple idea, implement it perfectly, and then build upon it.
This contrasts with the approach that we took: we had the  great idea 
with all the different features and bells and whistles for the user,
but had to keep dropping one thing or another because the things that were
really necessary, the most basic parts, weren't rock solid because of the
bells and whistles. Basically, I learned that its better to set your
dream small and build bigger rather than dream big and build smaller.
There were a lot of good ideas I wish we would have had the time-- or working
infrastructure-- necessary to build. 
On a lower level, I learned that Ocaml is exceedingly frustrating but also
very gratifying when it works. The slide at the beginning of the year, 
"never have i done so much writing so little," now makes too much sense. 

\subsection*{Bryan}

I realized, perhaps too late, that languages like Ocaml require
their own coding style standards.  Before getting into writing the bulk 
of the code it would have been helpful to nail down a set Programming style.
Ocaml's structure deviates greatly from most other languages I have
used.  A consistent style would have made Ocaml, a language that was new
to all of us, more understandable.
